Use dynamic prime field with modulus sampled at runtime - #141

Resolves #136

Introduce DynField, a field with $\le 126$ bit modulus that is squeezed from Fiat-Shamir transcript after the commitment and statement are bound. Number of bits to use in this prime depend on the claim shape.

A lot of code is shared with Fq, this shared code has been moved to a new helpers module.

This field relies on a globally shared modulus, and on an assumption that nobody would change that while field elements still exists. This convention is sadly not enforced by the type system.
[Remark: We could avoid this problem completely by passing around FieldConfig, but that's a bit cumbersome]

To sample a random prime, we use small prime numbers table sieve, followed by Miller-Rabin primality test, based on the PoC repo implementation.

E2E performance is quite close to static field, and can be optimized further. This is notable given that P/V can no longer do prime projection at the setup phase (setup got a bit faster).

Notable tricks used:

• Constraint matrices A, B, C are now prepared in two stages, integer ones are prepared in the setup as before, and P/V project them onto a field after the prime is drafted.
• When used this way, constraint matrices are hashed in their integer forms.
  • It's still possible to construct constraint matrices with field elements from the start, in this case field elements are hashed as before.
• Constraint matrix coefficients are now stored as flat Vec<_>, with Layout specifying the sparse matrix layout.
• BigInt to Field projection has been optimized for u128-wide cases (in practice - pretty much all of them)

Performance

To measure performance, I used a circuit sha256-2kb

RUSTFLAGS="-C target-cpu=native" cargo run --release -p bitz-cli -- circuit-e2e --circuit sha256-2kb

Notes:

• SHA-256 does not technically need a random prime for soundness
• In the main branch we normally use Fq<Q100>, a 100-bit prime. To make it comparable, I used Fq<2230695117703373733444658220249201783>